In the field of database systems, large amounts of information are constantly being retrieved, updated, and restored. Databases find uses in a variety of information intensive areas wherein large amounts of data need to be stored and accessed.
One such area is in transaction processing such as a bank teller machine which accesses a large central database in which all customer account information is stored. Through the bank teller machine, a customer performs a transaction such as withdrawing a certain amount of funds that exist in the customer's account. The database management system (or DBMS), which controls access of all the transactions to the database, interprets the customer's account action, and inquires as to whether the desired amount of funds to be withdrawn exist in the customer's account. If the funds are shown to exist in that database's files, the information for that account is updated by the amount desired to be withdrawn. The updated information is then restored to the database.
One problem in the art with on-line transaction processing such as the bank teller machine is that multiple teller machines must access the same database of information. If two bank teller machines simultaneously receive requests to withdraw a certain amount of funds from the same customer's account then the account may be overdrawn because both machines have, at the same moment in time, identical account information. As a result, the art has developed locking protocols for the DBMS such that one record is locked as one transaction is being processed with that record so that duplicate copies of the same record do not exist simultaneously.
The locking protocols known in the art take a variety of forms and can be CPU intensive when used concurrently with the other activities of the host processor. The DBMS host processing unit has to perform locking checks according to the protocol implemented in the database system in addition to all the retrieval, updating, and storage intensive work. Of particular interest to an understanding of the background of this invention is the Commit.sub.-- LSN idea, a discussion of which can be found in Mohan, "COMMIT.sub.-- LSN: A Novel and Simple Method for Reducing Locking and Latching in Transaction Processing Systems", Proceedings of VLDB, (AUG 1990).
In the art, database users query millions of pages of information on disk to gather information to make mission critical decisions. Such applications are known as decision support applications. For instance, a marketing person for a large retail manufacturer wants to cross reference millions of pages of files on disk in order to determine which was the best performing product over the last fiscal quarter. To do so, the DBMS would have to access most of the pages it has stored in the database to answer the query before filtering and assembling the desired information for presentation to the user. Meanwhile, the individual stores and manufacturing centers of the large retail chain would have to be able to access the database for information retrieval and updating. Due to the processing of the decision support query the host processor can become extremely busy. If the host becomes too busy, the overall response time for the entire database system degenerates.
Therefore, a basic problem in the art has been to try to off-load the amounts and kinds of work that have been traditionally performed by the host processor to specialized processors or disk controllers so as not to over-utilize the host and to lessen memory demands on the database system while allowing simultaneous updates to the same data by the host yet does not expose uncommitted data to a query which may be partially or wholly processed by the off-load processor.